2.1 Direct Rendering Benefits

 

 

Table 1: A comparison of the ``fast path'' steps involved implementing glReadPixels for the indirect and direct fast path cases. The extra steps involve data copying; protocol packing, unpacking, and dispatching; and context switch overhead.

Table 1 breaks down the overhead of indirect rendering relative to direct rendering for the extreme and common cases. The extreme example demonstrates the high-level steps involved in executing the OpenGL glReadPixels command used for reading pixels from a window. The command in question requires data to be returned to the application. In the indirect case, this requires a context switch to the X server and back to the OpenGL program. And the pixel data returned is copied three times, as opposed to a single copy in the direct rendering case. While glReadPixels requires a round-trip to the X server to return the pixel data, most OpenGL commands return no data.

For most OpenGL commands, the context switch overhead can be amortized over multiple GLX requests by streaming protocol requests. The table's glVertex3f example (whereby OpenGL sends a 3D vertex to the hardware; a very common OpenGL operation) is handled in this way. Even with streaming, the indirect case incurs the overhead of encoding, transport, and decoding GLX protocol for requests and replies.

The direct case can eliminate the overhead associated with context switching between the OpenGL program and the X server, protocol encoding, transport, and decoding when performing OpenGL rendering. Direct rendering also improves cache and TLB behavior by avoiding frequent context switches and multiple active contexts [3].

The examples in Table 1 assume the ``fast path'' of SGI's OpenGL implementation is taken. Being on the ``fast path'' means the system resources for direct rendering (discussed in detail later) are already made available. Unless resources are in contention or resources are being used for the first time, the ``fast path'' is the norm.